User and terminal mobility is key to the success of current and future generations of cellular networks. Whilst mobility issues associated with conventional circuit-switched calls are essentially resolved, challenges remain in respect of provisioning IP-based data services. A number of mobility solutions for IP have been proposed. These include Mobile IP where a mobile node is allocated a permanent IP address within its home network, and registers a care-of-address with the home network when the mobile node is roaming.
Another solution to the IP mobility problem is to separate the identification and location functions from each other, and this is the approach taken in the Host Identity Protocol (HIP) proposal (R. Moskowitz, P. Nikander, P. Jokela, “Host Identity Protocol”, Internet Draft, work in progress, draft-ietf-hip-base-05, IETF, 2006). HIP separates the location and identity roles of IP addresses by introducing a new name-space, the Host Identity (HI). In HIP, the Host Identity is basically a public cryptographic key of a public-private key-pair, and is generated from and linked to the private key. The public key identifies the party that holds the only copy of the private key. A host possessing the private key of the key-pair can directly prove that it “owns” the public key that is used to identify it in the network.
The HIP Host Identity (HI), being a public key, can be quite long and is therefore not practical in all situations. In HIP, the HI may be represented with a 128-bit long Host Identity Tag (HIT) that is generated from the HI by hashing it. Thus, the HIT identifies a HI. Since the HIT is 128 bits long, it can be used for IPv6 applications directly as it is exactly the same length as IPv6 addresses.
When HIP is used, the upper layers, including the applications, no longer see the IP address. Instead, they see the HI (or HIT) as the “address” of the destination host. The IP addresses no longer identify the nodes; they are only used for routing the packets in the network. The HIs (or HITs) which the applications use, must be mapped to the corresponding IP addresses before any packets leave a host. This is achieved in a new Host Identity Layer. FIG. 1 (PRIOR ART) of the accompanying drawings illustrates the various layers in HIP, comprising the standard transport layer 4, network layer 8 and link layer 10, with a process 2 communicating with the transport layer 4 below it. With HIP, a new Host Identity Layer 6 is disposed between the transport layer 4 and the network layer 8.
FIG. 2 (PRIOR ART) of the accompanying drawings illustrates the operation of the four-way handshake base protocol of HIP. The negotiating parties are referred to as the Initiator, starting the connection, and the Responder. The Initiator begins the negotiation by sending an I1 packet that contains the HITs of the nodes participating in the negotiation. The destination HIT may also be zeroed, if the Responder's HIT is not known by the Initiator. When the Responder gets the I1 packet, it sends back an R1 packet that contains a puzzle to be solved by the Initiator. The protocol is designed so that the Initiator must do most of the calculation during the puzzle solving, and requires access to the private key corresponding to the HI. This gives some protection against DoS attacks. The R1 initiates also the Diffie-Hellman procedure, containing the public key of the Responder together with the Diffie-Hellman parameters. Once the R1 packet is received, the Initiator solves the puzzle and sends a response cookie in an I2 packet together with an IPsec SPI value and its encrypted public key to the Responder. The Responder verifies that the puzzle has been solved, authenticates the Initiator and creates the IPsec ESP SAs. The final R2 message contains the SPI value of the Responder.
The SAs established as a result of the HIP base-exchange are bound to the Host Identities, represented by the HITs. However, the packets travelling in the network do not contain the actual HI or HIT information. Rather, an arriving packet is identified and mapped to the correct SA using the Security Parameter Index (SPI) value in the IPsec header.
From the above it will be clear that changing the location information in the packet does not create any problems for the IPsec processing. The packet is still correctly identified using the SPI. If, for some reason, the packet is routed to a wrong destination, the receiver is not able to open the packet as it does not have the correct key.
When an outgoing packet arrives at the HI layer from the above layer, the destination HI or HIT is verified from the IPsec SADB. If an SA matching to the destination HI or HIT is found, the packet is encrypted using the session key associated with the SA. The HI or HIT is mapped to the correct destination IP address. At the receiving host, the SPI value is used to find the correct SA from the IPsec SADB. If an entry is found, the IP addresses can be changed to corresponding HITs and the packet can be decrypted using the session key.
A HIP Mobile Node (HMN) moving in the network may change the point of attachment to the Internet relatively frequently. When the connection point is changed, so is the IP address. This changed location information must be sent to the peer nodes, i.e. HIP Correspondent Nodes (HCN). The same address can also be sent to a Rendezvous Server (RVS) of the HMN, so that the HMN can be reached also via a more stable point. The HIP Mobility and Multi-homing protocol (P. Nikander, J. Arkko, P. Jokela, T. Henderson, “End-Host Mobility and Multihoming with Host Identity Protocol”, Internet Draft, work in progress, draft-ietf-hip-mm-03, IETF, 2006) defines an update (UPDATE) packet that carries the LOCATOR parameter which contains the current IP address of the HMN. When the HMN changes location and IP address, it generates an UPDATE packet, signs the packet with the private key matching to the used HI, and sends the packet to the HCN and to the RVS.
When the HCN receives an UPDATE packet, it must start an address verification process for the IP address that is included in the UPDATE packet. The address verification is needed to avoid accepting false updates from the HMN. It sends an update acknowledgement (UPDATE-ACK) packet to the address that was in the UPDATE packet. When the HMN receives an UPDATE-ACK that matches the UPDATE sent earlier, it may start using the new IP address for sending data to HCN. After the HCN has received the first data packet from the new address, the address verification is completed and it can add the IP address as the location information of the HMN.
The HIP update exchange is also used for the purpose of rekeying. Rekeying is independent of location updates, as a mobile host may update its location without creating new IPsec security associations.
HIP UPDATE messages contain a HIP sequence number within the signed content. Synchronisation of sequence numbers is maintained by the HMN and the HCN at the respective HIP layers (a sequence number is maintained for each peer-to-peer HIP session). Each time the HMN sends an update message, the sequence number is incremented. An HCN will reject an UPDATE message if it does not contain the expected sequence number, e.g. if the sequence number has already been used. The use of sequence numbers in this way protects the peer node against so-called replay attacks (and a resulting denial-of-service).
HIP may be employed to handle mobility of mobile nodes that are attached to an access network that is itself mobile. Trains, busses, airplanes and Personal Area Networks (PANs) are examples of use cases where different moving network technologies can be applied. The moving network is a cluster consisting of mobile nodes (MNs) and one or more mobile routers (MRs). A mobile router connects the moving network to the Internet, and may change its point of attachment as it moves, i.e. a mobile router handoff. The mobile nodes in the moving network change their topological location together with the mobile router.
Within a moving network, each mobile router broadcasts “beacons” to advertise its existence. A single beacon contains the identity of a router operator. The mobile router may broadcast serially different kind of beacons, each of them including a different operator's identifier (e.g. where a single router is shared by several operators). The mobile node identifies the received beacon using a stored list of trusted operator identifiers. It allocates an IP address to itself and triggers an attachment exchange with the mobile router. The mobile node uses the HIP base protocol to register itself to the services offered by the mobile router. In this process, the mobile routers provides to the mobile node a pointer to the operator's authorisation certificate. This certificate authorises the mobile router to assign addresses, signal, and forward messages on behalf of the operator's clients. After validating the received certificate, the mobile node delegates forwarding and signalling rights to the mobile router.
The efficiency of a moving network can be significantly enhanced by allowing a mobile node to delegate to a mobile router the sending of location updates to peer nodes on behalf of the mobile node. A mobile node authorises a mobile router to send location updates by providing it with a further certificate signed with the HI of the mobile node. The lifetime of the certificate is the expected stay of the mobile node in the moving network. Each certificate issuer also keeps a list of the certificates that have a valid lifetime. When performing a location update on behalf of a mobile node, the mobile router sends the certificate to the peer node. This approach is described further in GB2381423. When a mobile node leaves a moving network, after movement it sends to peer nodes a list of certificate hashes for certificates that are no longer valid. Alternatively, a peer node may accept only certificates that are valid longer than the last received certificate. The latest certificate signed by the issuer revokes all the earlier signed certificates by the same issuer. In this way, the peer host only accepts messages with the latest timestamp. A modified approach is to store the certificate at some central location and to include in the update message sent by the mobile router a pointer to this location, the peer node then downloading the certificate from the central location.
FIG. 3 (PRIOR ART) illustrates schematically a mobile node attached to a moving network via a mobile router. The mobile node delegates the signalling rights to the mobile router at step (1). At step (2) the mobile router delegates the signaling rights further to the Signalling Proxy. At step (3), after a hand-off has been performed for the mobile router to a new internet access point of the operator's network, the mobile router runs a single update exchange with the proxy on behalf of the mobile node. At step (4), the proxy runs an update exchange with each peer node.